企业级SaaS平台落地经验：手机当扫码枪小程序在零售库存管理的离线同步技术探析
去年秋天，我们团队接手了华东地区一家拥有三百多家门店的社区生鲜连锁的数字化改造项目。甲方提出了一个很现实的要求：能不能别再让门店买那种一两千块一台的工业级扫码枪了？店员流动性那么大，枪丢了、坏了都是成本，培训新兵用枪也得半天。他们希望直接用店员自己的智能手机，或者门店配发的普通安卓机，打开微信里我们的SaaS小程序，摄像头一扫就能完成入库、盘点、出库。
这需求听起来简单，不就是调用一下 `wx.scanCode` 吗？但真正在零售库存管理这个重场景下做企业级SaaS落地，我们才发现有大量的坑。尤其是离线同步这件事，绝对不是把数据暂存一下那么简单。
为什么必须要搞定离线同步？去过商超仓库的人都知道，很多生鲜仓、地下冷库信号极差，甚至为了省电直接关了Wi-Fi。店员拿着手机去盘点，扫着扫着小程序断网了，如果这时候系统卡死或者数据丢了，盘点就得重来，那在真实业务里是要出大乱子的。我们一开始也试过纯云端实时校验，结果弱网环境下扫码延迟高达两三秒，店员误以为没扫上，连续扫了三次，后台库存直接多出了两倍的假数据。
所以在第二代架构里，我们彻底把“手机当扫码枪”的小程序做成了具备本地边缘计算能力的轻终端。技术上，我们重点啃下了三块硬骨头。
先说本地可靠存储与指令日志化。小程序本身运行环境受限，早期我们想用简单的 `localStorage` 存扫码记录，后来发现容量和性能根本扛不住几千条盘点数据。我们后来基于小程序的文件系统能力，自己撸了一个类 SQLite 的轻量 KV 加追加日志（Append-Only Log）结构。关键点是，本地不存“当前库存状态”，只存“操作指令”——比如“条码A，入库 10，时间戳T，操作人U，设备指纹D”。这样即便断网一天，手机里攒了几千条指令，数据体积也极小，且绝对不会乱。
再就是幂等与冲突处理的业务语义化。很多做SaaS的同行在这里容易犯懒，直接用“最后写入获胜（LWW）”策略，这在库存场景会死得很惨。比如店员 offline 盘点时把某商品核为0，同时另一台在线设备做了出库，云端如果用LWW把库存覆盖成0，实际仓库还有货。我们的做法是把同步过程设计成“流水合并”而非“状态覆盖”。后台接收到离线指令日志后，根据业务规则做增减计算。每条指令在生成时都带一个 UUID，后端做幂等表校验，就算弱网重发也不怕重复扣减。
最后是弱网恢复与批量提速。我们设计了一个前后台长连接心跳（用小程序 WebSocket 做保活探测），一旦检测到网络从断到连，客户端立刻把积压的指令日志打包、用 Protocol Buffers 压缩后批量推送到云端队列。实测在一家门店一次大盘点约2000条扫码记录，网络恢复后同步耗时从原先的几十秒降到了3秒以内。
说实话，这套方案在刚灰度的时候，我们运维同学还担心数据一致性，但跑了几个月，跨门店库存调拨的错账率降到了万分之一以下。回过头看企业级SaaS在零售端的落地，技术未必需要多前沿，但必须尊重一线物理环境的粗糙。把手机摄像头调教成不输硬件枪的扫码速度，靠的是本地算法优化；而让店员敢在没网的仓库里放心盘货，靠的就是这套扎实的离线同步机制。如果你也在做类似的企业应用，别迷信全云端实时，先想想断网了你的程序会不会变成砖头。
微信号：18581869297
